Freaks Macintosh Archive/Freaks Macintosh Archive.bin/Freaks Macintosh Archives/Textfiles/coloredbooks/PeachBook.sit.hqx/Peach Book

Text File | 1997-11-17 | 60KB | 1,797 lines

 A GUIDE TO WRITING THE SECURITY FEATURES USERS GUIDE FOR
TRUSTED SYSTEMS



 A GUIDE TO WRITING THE SECURITY FEATURES USERS GUIDE FOR
TRUSTED SYSTEMS



NCSC-TG-026


Library No. 5-237,294


Version t
FOREWORD



The National Computer Security Center is publishing A Guide to
Writing the Security Features User's Guide for Trusted Systems
as part of the "Rainbow Series" of documents our Technical
Guidelines Program produces. In the Rainbow Series, we discuss
in detail the features of the Department of Defense Trusted Computer
System Evaluation Criteria (DoD 5200.28-STD) and provide guidance
for meeting each requirement. The National Computer Security Center,
through its Trusted Product Evaluation Program, evaluates the
security features of commercially-produced computer systems. Together,
these programs ensure that organizations are capable of protecting
their important data with trusted computer systems.


A Guide to Writing the Security Features User's Guide for Trusted
Systems expands on the Trusted Computer System Evaluation Criteria
requirement for a Security Features User's Guide by discussing
the intent behind the requirement and the relationship it has
to other requirements in the Trusted Computer System Evaluation
Criteria. The guide's target audience is the author of the Security
Features User's Guide for a specific trusted system undergoing
evaluation as a trusted product; however, many of the recommendations
apply to any system that must satisfy the Trusted Computer System
Evaluation Criteria requirements.


As the Director, National Computer Security Center, 1 invite your
recommendations for revision to this technical guideline. We plan
to review and update this document periodically in response to
the needs of the community.


Please address any proposals for revision through appropriate
channels to:

 • National Computer Security Center
 • 9800 Savage Road




Ft. George G. Meade, MD 20755-6000


Attention: Chief, Standards, Criteria, and Guidelines Division

 • Patrick R. Gallagher, September 1991
 • Director
 • National Computer Security Center





INTRODUCTION

1.1 PURPOSE



This guideline explains the motivation and meaning of the Department
of Defense Trusted Computer System Evaluation Criteria (TCSEC)
requirement for a Security Features Users Guide (SFUG), which
reads as follows:


"A single summary, chapter, or manual in user documentation
shall describe the protection mechanisms provided by the TCB,
guidelines on their use, and how they interact with one another."
[TCSEC; x.x.4.1]


The reader is assumed to be the potential author of a SFUG; to
be familiar with the basic principles of technical writing, computer
science, and trusted systems; and to have a detailed understanding
of the specific trusted system that will be described in the SFUG.
1.2 SCOPE



This guideline identifies and discusses the considerations that
influence the development and evaluation of a SFUG, such as its
audience, content, and organization. It is intentionally descriptive,
as opposed to prescriptive, in its discussion of the SFUG requirement.
That is, it describes the various approaches to writing a SFUG
that have been accepted by trusted product evaluators in the past,
without making judgments about the "correct" ones to
choose - although preferred approaches may be noted.


Throughout this guideline there will be statements made that are
not included in the TCSEC as requirements.  These statements will
fall into three categories.  First, some describe a strongly recommended
course of action: these statements will be prefaced by the word
"should."  Second, others describe one of several equally
appropriate recommended courses of action: these statements will
be prefaced by the word "could."  Finally, a few suggest
an optional course of action: these statements will be prefaced
by the word "can."
1.3 ORGANIZATION



The remainder of this guideline presents information that may
be useful to a writer developing a SFUG. Chapter 2 discusses the
developmental aspects of writing the SFUG, including the audience
and possible packaging options, presentation styles, and the security
topics that should be addressed in the SFUG (as derived from TCSEC
feature requirements). Chapter 3 contains two example annotated
outlines of SFUGs to illustrate some of the topics discussed in
the body of the guideline and provide a starting point for the
reader to develop a SFUG. The bibliography includes a list of
the documents accepted as SFUGs for all products on the Evaluated
Product List (EPL) at the time the guideline was published.
2. DEVELOPING THE SECURITY FEATURES USER'S  GUIDE



 The primary purpose of a SFUG is to explain how the security
mechanisms in a specific system work, so that users are able to
consistently and effectively protect their information. To properly
communicate this information, the SFUG author must identify the
audience for the SFUG and the information that audience needs
to use the security mechanisms in the system and then select an
appropriate way to present the information.
2.1 AUDIENCE AND PACKAGING



The SFUG requirement starts with "A single summary, chapter,
or manual in user documentation . . .,, "User" in this
context refers to a person who uses the system, but has no special
privileges to affect the configuration of the system. The user
for most general purpose trusted systems is often assumed to be
a person with little or no computer experience, but this is not
always the case. For example, the users of the UNIX system
have traditionally been considered programmers or computer professionals
with fairly extensive knowledge of computer concepts. In any system,
the users are the audience for the SFUG and the SFUG author will
have to characterize them to determine both the format and the
level of discourse for the material presented in the SFUG.


In many cases, the SFUG requirement is satisfied by changing an
existing document, which is one of the reasons that the SFUG requirement
is so general.


As stated in the requirement, the SFUG could be:

 •  A summary of the security features and user responsibilities,
 •  A chapter devoted to these issues, or
 •  A whole manual devoted to security.







Some presentation schemes that previous participants in the Trusted
Product Evaluation Program have used include:


A separate manual devoted to the general user of the system that
covers the security features and responsibilities pertaining to
users. This is usually the best choice when a document of this
sort is already in place and the security functions have always
been present in the system in some form anyway. For a system in
which user services are provided by individual subsystems, one
of which provides all the security functionality, and the user
guide is the collection of user guides `for the individual subsystems,
the SFUG would most likely be a stand-alone manual addressing
only the security issues.

 •  A subsection of the manual produced to satisfy the
Trusted Facility Manual (TFM) requirement of the TCSEC. From a
security standpoint, this is considered unwise, since it tends
to make the system configuration and vulnerability information
available to anyone looking for information on how to use the
security features of the system. From a documentation standpoint,
it seems the easiest, since it places all of the security discussion
in one place and allows a certain amount of synergy in the writing
process, i.e., privileged users do many of the same activities
as general users. This approach eliminates the need to document
those facilities in two places.
 •  A chapter or an appendix of a user manual that discusses
the user's security responsibility and then provides an index
to the detailed discussions of individual functions that are already
part of the general user manual. An extension of this could be
a small pamphlet that does the same thing but can be reproduced
separately and given out as needed - something like a pocket guide
to system security.







Trusted product evaluators tend to favor centralization of information,
because that makes it easier to determine whether the system satisfies
the TCSEC (Orange Book) requirements. Given that bias, bullet
one would usually be the most preferred option, since it satisfies
the requirement in one unique place. Bullet two is a less desirable
option, because, in addition to the procedural security considerations,
it requires some discrimination to identify which parts of the
document satisfy the SFUG requirement and which parts satisfy
the TFM requirement. Bullet three is least desirable for two reasons.
First, it involves pointers to other information, making it more
cumbersome for both evaluators and users to get to some aspects
of the information. Second, there might be a tendency to make
the document so terse that it excludes some information that is
relevant to system security.
2.2 PRESENTATION



The SFUG provides the users of the system with the necessary background
and specific information to use the protection features of the
system correctly. Its purpose is twofold. First, it provides the
information that a user needs to enter the system and start working-within
the system security constraints. Second, it explains the user's
role in maintaining the security of the system. Its scope should
be limited to documenting only the features available to all users
and only the responsibilities that all users have for system security.
To accomplish this purpose, within the scope, the SFUG should
explain what security means in the system, what security features
are present and why, how the features work, and how to use the
features properly. The SFUG should be clear, concise, and complete
to increase its readability.


This information can be organized either by the security features
present in the system or by the tasks performed by a user that
require the use of these features. A feature-oriented presentation
is more natural to a user who is already familiar with the system.
In the SFUG, this organization would usually look like the TCSEC
itself, with descriptions of each feature required by the TCSEC
and explanations of the commands that make those features available
to users. A task-oriented presentation is the more common approach
taken in most user manuals, since it is oriented towards the specific
actions that are necessary to enter a system and start working.
Such a presentation will often take the form of a tutorial that
describes the interactions that a user will usually have with
the system, e.g., logging on, setting file access, changing the
password, etc.
2.3 CONTENT



Because this guideline is devoted to explaining a TCSEC requirement,
it will consider the content of a SFUG only from the perspective
of the features required by the TCSEC that should be documented
in the SFUG. OtheLr security-relevant features not addressed by
the TCSEC (e.g., object downgrading or network commands) might
also be included in the SFUG, but will not be discussed in this
guideline.


The remainder of this section will list the features required
by the TCSEC, identify the specific requirements that define them,
and discuss how they apply to the SFUG. Many of the requirements
cited use the acronym TCB, which expands to Trusted Computing
Base. As defined in the TCSEC, the TCB is:


"The totality of protection mechanisms within a computer
system-including hardware, firmware, and software-the combination
of which is responsible for enforcing a security policy. A TCB
consists of one or more components that together enforce a unified
security policy over a product or system. The ability of a TCB
to correctly enforce a security policy depends solely on the mechanisms
within the TCB and on the correct input by system administrative
personnel of parameters (e.g., a user's clearance) related to
the security policy." [TCSEC, p. 116]
2.3.1 TECHNICAL SECURITY POLICY]



The technical security policy is the description of the access
control model that the system enforces. This description can be
either informal or formal for classes Cl through BI, but classes
B2 to Al must have a formal description. The TCSEC design documentation
requirement mandates that the informal description exist for all
criteria classes where it states:


"Documentation shall be available that provides a description
of the manufacturer's philosophy of protection . . .," [x.x.4.4]


Starting at BI, the design specification and verification requirement
strengthens this notion of a technical security policy with the
explicit requirement that:


"An informal or formal model of the security policy supported
by the TCB shall be maintained over the life cycle of the ADP
system and demonstrated to be consistent with its axioms."


[x.x.3.2.2]


At class B2, the design specification and verification requirement
is changed to mandate a formal technical security policy model.
Classes 83 and Al incorporate new requirements for additional
supporting documentation thatk makes it possible to trace the
basis for each feature in the system from the technical security
policy to the implementation.


In the context of the TCSEC, neither the philosophy of protection
nor the formal model have to be available to the user; however,
the fact that the features of the system flow from these fundamental
statements makes either one an appropriate starting point for
describing how the system works. The philosophy of protection
is probably the better choice for the SFUG, since it is usually
written in a more intuitive style than a precisely stated security
policy statement. In either case, the technical policy would be
presented early in the SFUG to provide the overall context for
the rest of the discussion, effectively becoming the thesis for
the SFUG.
2.3.2 IDENTIFICATION AND AUTHENTlCATlON



The single largest and most crucial section of the SFUG, both
from the perspective of the TCSEC and of overall system documentation,is
the section that discusses how users identify and authenticate
themselves (i.e., logon) to the system. The process of identification
and authentication (l&A) defines the identity of the subject
that the TCB creates to act on the user's behalf. For division
B and A multilevel systems, the I&A process defines the upper
and lower bounds on the security level of the subject as well.
All subsequent access control decisions depend on this information
being correct. The SFUG should therefore be very specific in describing
both the l&A procedures and the user's responsibilities for
protecting any information that is expected to be kept secret
(e.g., passwords or personal identification numbers).


The TCSEC requirement for division C computer systems is shown
below, with bold type showing the C2 requirements that go beyond
those at Cl.


"The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is
expected to mediate. Furthermore, the TCB shall use a protected
mechanism (e.g., passwords) to authenticate the user's identity.
The TCB shall protect authentication data so that it cannot be
accessed by any unauthorized user. The TCB shall be able to enforce
individual accountability by providing the capability to uniquely
identify each individual ADP system user. The TCB shall also provide
the capability of associating this identity with all auditable
actions taken by that individual." [2.2.2.1]


Based on this requirement, the SFUG for a division C system should
describe the identification process, including the use of a protected
authentication mechanism. To complement the protection that the
TCB must give the authentication data, the SFUG should make it
clear that the user must protect the data too, for example, by
not sharing a password with other users or writing it down on
a sheet of paper next to the terminal.


For divisions B and A, the addition of multiple security levels
changes the requirement, primarily by requiring the use of a user'sclearance
as a bound on the security label of any subject that the TCB creates
for that user. The BI requirement, which does not change for the
higher classes, is shown below, with bold type showing additional
wording and struck-out type showing wording that was deleted.


"The TCB shall require users to identify themselves to it
before beginning to perform any other actions that the TCB is
expected to mediate. Furthermore, the TCB shall maintain authentication
data that includes information for verifying the identity of individual
users (e.g., passwords) as well as information for determining
the clearance and authorizations of individual users. This data
shall be used by the TCB to authenticate the user's identity and
to ensure that the security level and authorization of subjects
external to the TCB that may be created to act on behalf of the
individual user are dominated by the clearance and authorization
of that user.


The TCB shall protect authentication data so that it cannot be
accessed by any unauthorized user. The TCB shall be able to enforce
individual accountability by providing the capability to uniquely
identify each individual ADP system user. The TCB shall also provide
the capability of associating this identity with all auditable
actions taken by that individual." [3.1.2.1]


For all division B and A systems, the SFUG should incorporate
a discussion of the relationship between a user's clearance (i.e.,
his or her general authorization to see information of a particular
sensitivity-whether or not it is electronic) and the security
level that the TCB associates with a particular subject (e.g.,
computer process or interactive session) that is acting on that
user's behalf. Additionally, the practical consideration of how
to establish the security level of that subject, for example,
by using a logon option or a specific terminal, should be explained
in the SFUG.


Starting at B2, there is an additional requirement for a trusted
path to strengthen the confidence of both the user and the TCB
that the l&A process is happening correctly. This requirement
is shown below in both the B2 and B3/Al forms.


"The TCB shall support a trusted communication path between
itself and user for initial login and authentication.


Communications via this path shall be initiated exclusively by
a


user." [3.2.2.1.1(B2)]


"The TCB shall support a trusted communication path between
itself and  users for use when a positive TCB-to-user connection
J5 required (e.g., Iogin, change subject security level). Communications
via this trusted path shall be activated exclusively by a user
or the TCB and shall be logically isolated and unmistakably distinguishable
from other paths." [3.3.2.1.1


(B3/Al)]


Trusted path is useless if it is not used; therefore, the SFUG
should be written so that the user understands how to initiate
the trusted path, especially at logon, and why it is important
to do so. For systems that satisfy the B3 trusted path requirement,
the SFUG should also explain how the initiation of a trusted path
during a session, whether by the user or the TCB, affects the
currently running subject, as well as how to recognize the trusted
path.
2.3.3 DISCRETIONARY ACCESS CONTROL FACILITY



The discretionary access control (DAC) facility provides the mechanism
by which the individual user can control access to his or her
data. Some form of DAC is required for every class of the TCSEC.
After the procedures for identifying and authenticating themselves
to the system, the DAC facilities will be the aspects of the system
security of most interest to most users.


The DAC facility is first defined by the Cl DAC requirement that:
"The TCB shall define and control access between named users
and named objects (e.g., files and programs) in the ADP system.
The enforcement mechanism (e.g., self/group/public controls, access
control lists) shall allow users to specify and control sharing
of those objects by named individuals or defined groups or both."
[2.1.1.1] At C2 this requirement is enhanced to read (bold type
shows added words): "The TCB shall define and control access
between named users and named objects (e.g., files and programs)
in'the ADP system. The enforcement mechanism (e.g., self/group/public
controls, access control lists) shall allow users to specify and
control sharing of those objects by named individuals, or defined
groups of individuals, or by both, and shall provide controls
to limit propagation of access rights. The discretionary access
control mechanism shall, either by explicit user action or by
default, provide that objects are protected from unauthorized
access. These access controls shall be capable of including or
excluding access to the granularity of a single user. Access permission
to an object by users not already possessing access permission
shall only be assigned by authorized users." [2.2.1.1]


After this it remains the same until B3, when it is changed to
read (bold type shows added words, struck-out type shows deleted
words):


"The TCB shall define and control access between named users
and named objects (e.g.,files and programs) in the ADP system.
The enforcement mechanism (e.g., self/group/public controls, access
control lists) shall allow users to specify and control sharing
of those objects by named individuals, or defined groups of individuals,
or by both, and shall provide controls to limit propagation of
access rights. The discretionary access control mechanism shall,
either by explicit user action or by default, provide that objects
are protected from unauthorized access. These access controls
shall be capable of specifying, for each named object, a list
of named individuals and a list of groups of named individuals
with their respective modes of access to that object.


Furthermore, for each such named object, it shall be possible
to specify a list of named individuals and a list of groups of
named individuals for which no access to the object is to be given.
including or excluding access to the granularity of a single user.
Access permission to an object by users not already possessing,,access
permission shall only be assigned by authorized users. [3.3.1.1]


For any version of this requirement, the goal for the SFUG author
is the same -to describe to users how to use the DAC enforcement
mechanism to control access to the objects that they own. The
SFUG should provide enough information for the user to understand
what a named object, a named user, and a group are, as well as
what types of objects can be controlled with DAC. It should also
explain how a new user or group is defined to the system. The
SFUG should also describe the process by which access rights are
initially determined and then propagated. Finally, the SFUG should
describe the system commands and procedures for using the DAC
facility.
2.3.4 ELECTRONIC LABELS



The distinguishing feature of all division B and A computer classes
is the electronic label. An electronic label is an attribute of
each subject and object under TCB control that indicates the sensitivity
of the information that a subject is authorized to see or that
is contained in an object. The real world equivalents of these
concepts are security clearances and classification markings.
Many users who are familiar with these real world examples have
trouble adapting to electronic labels; therefore, the SFUG written
for a multilevel system should discuss labels and their effect
on a user's actions. The basic label requirement is defined by
the following words at Bl: "Sensitivity labels associated
with each subject and storage object under its control (e.g.,
process, file, segment, device) shall be maintained by the TCB.
These labels shall be used as the basis for mandatory access control
decisions. In order to import non-labeled data, the TCB shall
request and receive from an authorized user the security level
of the data, and all such actions shall be auditable by the TCB."
[3.1.1.3] At B2, the first sentence is changed to read: "Sensitivity
labels associated with each ADP system resource (e.g., subject,
storage object, ROM) that is directly or indirectly accessible
by subjects external to the TCB shall be maintained by the TCB."
[3.2.1.3] This reflects the general B2 through Al requirement
that all computer resources be under the control of the TCB.


Another label-related requirement that affects the users of a
system is the one for labeling human-readable output, which states
that:


"The ADP system administrator shall be able to specify the
printable label names associated with exported sensitivity labels.
The TCB shall mark the beginning and end of all human-readable,
paged, hardcopy output (e.g., line printer output) with human-readable
sensitivity labels that properly represent the sensitivity of
the output. The TCB shall, by default, mark the top and bottom
of each page of human- readable, paged, hardcopy output (e.g.,
line printer output) with human-readable sensitivity labels that
properly represent the overall sensitivity of the output or that
properly represent the sensitivity of the information on the page.
The TCB shall, by default and in an appropriate manner, mark other
(forms of human-readable output (e.g., maps, graphics) with human-
readable sensitivity labels that properly represent the sensitivity
of the output. Any override of these marking defaults shall be
auditable by the TCB." [3.1.1.3.2.3] The above requirement
is the same for classes Bl through Al.


These two requirements, for subject sensitivity labels and labeled
human-readable output, apply to any multilevel system; therefore,
the SFUG for all B and A level systems should, at the least, explain:

 •  How labels are attached to subjects and objects,
 •  The relationship between the "clearance"
that a user has and the label that is associated with a particular
computer session, and
 •  The reason for job and page labels on printed output
and terminal or window labels on computer displays (as well as
cautions about disabling the display of such labels).







The last requirement that affects users is one for subject sensitivity
labels that requires that:


"The TCB shall immediately notify a terminal user of each
change in the security level associated with that user during
an interactive session. A terminal user shall be able to query
the TCB as desired for a display of the subject's complete sensitivity
label." [3.2.1.3.3]


The above requirement applies to classes B2 through Al; therefore,
the SFUG for these systems should explain the mechanism used to
notify a user of a security level change.
2.3.5 MANDATORY ACCESS CONTROL FACILITY



Closely associated with, but separate from, the requirement for
labels is the requirement for mandatory access control (MAC).
MAC refers to the set of rules that control a subject's access
to an object based on the label attached to each.


The MAC facility is first defined by the BI MAC requirement that:
"The TCB shall enforce a mandatory access control policy
over all subjects and storage objects under its control (e.g.,
processes, files, segments, devices). These subjects and objects
shall be assigned sensitivity labels that are a combination of
hierarchical classification levels and non- hierarchical categories,
and the labels shall be used as the basis for mandatory access
control decisions. The TCB shall be able to support two or more
such security levels. The following requirements shall hold for
all accesses between subjects and objects controlled by the TCB:
A subject can read an object only if the hierarchical classification
in the subject's security level is greater than or equal to the
hierarchical classification in the object's security level and
the non- hierarchical categories in the subject's security level
include all the non-hierarchical categories in the object's security
level. A subject can write an object only if the hierarchical
classification in the subject's security level is less than or
equal to the hierarchical classification in the object's security
level and all the non-hierarchical categories in the subject's
security level are included in the non-hierarchical categories
in the object's security level. Identification and authentication
data shall be used by the TCB to authenticate the user's identity
and to ensure that the security level and authorization of subjects
external to the TC8 that may be created to act on behalf of the
individual user are dominated by the clearance and authorization
of that user." [3.1.1.4]


For classes B2 through Al, the requirement is enhanced to reflect
the pervasive TCB control required by these higher classes. (The
bold type in the following quote shows the additional wording,
while the struck-out type shows the phases deleted.)


"The TCB shall enforce a mandatory access control policy
over all resources (i.e., subjects, storage objects, and 1/0 devices)
that are directly or indirectly accessible by subjects external
to the TCB.


These subjects and objects shall be assigned sensitivity labels
that are a combination of hierarchical classification levels and
non-hierarchical categories, and the labels shall be used as the
basis for mandatory access control decisions. The TCB shall be
able to support two or more such security levels. The following
requirements shall hold for all accesses between all subjects
external to the TCB and all objects directly or indirectly accessible
by these subjects: A subject can read an object only if the hierarchical
classification in the subject's security level is greater than
or equal to the hierarchical classification in the object's security
level and the non-hierarchical categories in the subject's security
level include all the non-hierarchical categories in the object's
security level. A subject can write an object only if the hierarchical
classification in the subject's security level is less than or
equal to the hierarchical classification in the object's security
level and all -the non- hierarchical categories in the subject's
security level are included in the non-hierarchical categories
in the object's security level. Identification and authentication
data shall be used by the TCB to authenticate the user's identity
and to ensure that the security level and authorization of subjects
external to the TCB that may be created to act on behalf of the
individual user are dominated by the clearance and authorization
of that user." [3.2.1.4]


Because the TCB, rather than the user, controls the actual interaction
between the labels of subjects and objects, the SFUG only needs
to explain to users how MAC constrains their actions. This discussion
is probably most natural under the section that addresses the
technical security policy. In most cases, a user can have only
one effect on the MAC policy-to change the label for a session,
which is already described under either the discussion of identification
and authentication or labels.
2.3.6 TRUSTED FACILITY MANAGEMENT



Beginning at B2, there is a TCSEC requirement that: "The
TCB shall support separate operator and administrator functions."
[3.2.3.1.4]


This mandates a separation of duties in the administration of
computer systems that are supposed to be protecting information.
This corresponds to the natural separation of duties found in
most human activity. Although this is not a requirement until
B2, many sites that are concerned about security are instituting
programs `rvhere the responsibility for security administration
of the computer system is centralized in a person with the title
of computer, or information system, security officer (CSO or 1550,
respectively). Whether the computer system being described in
the SFUG satisfies the trusted facility management requirement
or not, the author of the SFUG for that system may want to postulate
the existence of such a position to represent the entity that
is responsible for security issues that are outside the control
of the users. This both allows the SFUG to be written in a more
active voice and simplifies the job of conveying distinctions
between user security responsibilities and site management security
responsibilities.
3. EXAMPLES OF SFUG PRESENTATION STYLES



This chapter presents two sample stand-alone SFUGs to show what
could go into a SFUG and possibly give the reader some ideas for
organizing a system specific SFUG. The actual contents and organization
of a real SFUG will be different to reflect the specific mechanisms
of the individual system and the organization of the rest of the
system documentation. The first example uses a feature-oriented
style presentation, while the second shows a task-oriented style.


In addition to these generic examples, the reader may find it
helpful to review the SFUGs of previously evaluated systems to
see what worked for them. Entries 2 through 16 in the bibliography
list the Final Evaluation Reports (FERs) for products on the Evaluated
Products List that had published FERs at the time this guideline
was printed. Each entry is annotated with the document(s) identified
in the FER as satisfying the SFUG requirement for that product.
THE FEATURE-ORIENTED SFUG



At a high level, the feature-oriented example SFUG is arranged
in the following fashion:

 • 1. INTRODUCTION TO THE SFUG
 • 2. SYSTEM SECURITY OVERVIEW

 • 2.1 SYSTEM PHILOSOPHY OF PROTECTION
 • 2.2 DEFINITION OF TERMS AND SERVICES
 • 2.3 THE INFORMATION SYSTEM SECURITY OFFICER
 • 2.4 USER SECURITY RESPONSIBILITIES


 • 3. SECURITY-RELATED COMMANDS FOR USERS

 • 3.1 USER IDENTIFICATION AND AUTHENTICATION

 • 3.1.1 Trusted Path
 • 3.1.2 Logging On to the System
 • 3.1.3 Password Considerations
 • 3.1.4 Changing Group Membership
 • 3.1.5 Changing Current MAC Authorizations
 • 3.1.6 Logging Off of the System
 • 3.1.7 I&A Errors and Their Causes


 • 3.2 DISCRETIONARY ACCESS CONTROL FACILITIES

 • 3.2.1 Setting DAC on Named Objects
 • 3.2.2 Default DAC Protection
 • 3.2.3 DAC Groups
 • 3.2.4 DAC Errors and Their Causes


 • 3.3 MANDATORY ACCESS CONTROL FACILITIES

 • 3.3.1 Printing Labeled Objects
 • 3.3.2 Accessing Single-Level Devices
 • 3.3.3 Accessing Multilevel Devices
 • 3.3.4 Downgrading Labeled Objects
 • 3.3.5 MAC Errors and Their Causes


 • 3.4 OBJECT MANIPULATION FACILITIES

 • 3.4.1 Object Creation, Reuse, and Deletion
 • 3.4.2 Importing Machine-Readable Objects
 • 3.4.3 Exporting Machine-Readable Objects
 • 3.4.4 Determining the Properties of Objects
 • 3.4.5 Object Manipulation Errors and Their Causes











The annotated outline follows.
1. INTRODUCTION TO THE SFUG


 •  This part of the SFUG should identify what the SFUG is, who
it is written for, what it will cover, and where to go for more
information, if needed.


2. SYSTEM SECURITY OVERVIEW


 •  This section provides the background on the overall operation
of the security controls in the system so that users can then
understand the options and actions of individual security-relevant
commands.



 •


2.1 SYSTEM PHILOSOPHY OF PROTECTION


 •  This section should describe the general environment for
which the system is designed and briefly explain how this environment
motivates the approach to protecting information stored in the
system. The purpose of this section is to lay the foundation for
the user's understanding of the system's security features, with
later sections detailing what specific security services are available
and when and how to use them.



 •


2.2 DEFINITION OF TERMS AND SERVICES


 •  This section should first introduce the terms that will be
used to describe the security services available in the system
and then proceed to introduce those services, without detailing
exactly how they are used. Recommended topics for this section
are:

 •  An explanation of the general concepts of subjects
and objects, followed by the identification of the subjects and
objects in the system.
 •  An explanation of object reuse and its role in protecting
information in the system.
 •  An explanation of the components of the l&A (identification
and authentication) process (e.g., user-id, password, or smartcard)
in the system and the importance of l&A to system security.
 •  An explanation of DAC, groups, privileges, protection
bits/ACLs, and any other terms and concepts related to the system's
DAC policy, followed by a description of how the DAC policy applies
to the systern subjects and objects.
 •  An explanation of MAC, security labels, sensitivity
levels, categories, authorizations, and any other terms and concepts
related to the system's MAC policy, followed by a description
of how the MAC policy applies to the system subjects and objects.







2.3 THE INFORMATION SYSTEM SECURITY OFFICER


 •  This section discusses the role of the Information System
Security Officer (1550) in maintaining the security of the system.
It can also explain which problems should be reported to the 1550
and which should be reported to the system administrator (if the
roles are separate). If the format of the SFUG allows it, this
section could have space for site-specific notes on the 1550/user
relationship.
 •








2.4 USER SECURITY RESPONSlBlLlTlES


 •  This section discusses the user's responsibilities with respect
to properly using the system security features. This would optimally
be a tutorial that teaches effective use of the system security
services, but any presentation that relates the security services
to the user's day-to-day use of the system is appropriate. Some
issues that might be addressed are:



 •  Authentication token (e.g., password or smartcard)
protection.
 •  Warnings about leaving a terminal unattended.
 •  Procedures for "locking" a process when the
terminal must be left unattended, but logged in.
 •  Default DAC access for named objects (e.g., files andkdirectories).
 •  Cautions about using programs that are not part of
the standard system configuration (e.g., utilities or applications
that have not been reviewed and tested by the system administrator(s)).
 •  Cautions about the effect of network access on system
and data security.


3.SECURITY-RELATED COMMANDS FOR USERS


 •  This section comprises the majority of the SFUG since it
describes in detail the commands and procedures for actually using
the system.





3.1 USER IDENTIFICATION AND AUTHENTICATION


 •  This section should step through the procedures for logging
on to and off of the system and for manipulating privileges and
participation in the system. Additionally, any of the errors that
might occur during the use of these commands and the corrective
actions should be described here.


3.1.1 Trusted Path


 •  In 82 and above systems, the first thing that a user will
have to do to Iogon is establish a trusted path between his terminal
and the system TCB. This section should describe that process.
For 83 and Al systems, this trusted path is available for any
direct interaction between the TC8 and the user; therefore, in-session
invocation of the trusted path and its effects on currently executing
processes should be described here.



 •


3.1.2 Logging On to the System


 •  The procedure for logging on to the system should be described.
If the system has MAC, the procedures for logging on with specific,
non-default authorizations should be described.


3.1.3 Password Consideration


 •  The procedures and commands for setting, changing, and protecting
passwords should be described.


3.1.4 Changing Group Membership


 •  In systems with the concept of DAC groups, the mechanisms
for users to specify the group membership(s) that should be used
in making DAC access decisions (if such capability is present)
should be described.





3.1.5 Changing Current MAC Authorizations


 •  In systems with MAC, if the user can change their current
authorization level and category set without logging off, the
mechanism and procedure should be described.


3.1.6 Logging Off of the System


 •  The command or procedure for logging off the system should
be described.


3.1.7 I&A Errors and Their Causes



The possible error messages that can occur when l&A commands
are improperly invoked should be noted and the correct or expected
inputs should be explained.
3.2 DISCRETIONARY ACCESS CONTROL FACILITIES


 •  This section should describe the DAC-related commands and
procedures for the system. This section will be present in some
form at all levels of the criteria.


3.2.1 Setting DAC on Named Objects


 •  This section should describe how users can set the discretionary
access permissions, and what the permissions mean, for the different
types of named objects in the system.


3.2.2 Default DAC Protection


 •  The means for determining and setting the default discretionary
access controls on user controlled or owned named objects should
be described.


3.2.3 DAC Groups


 •  When the capability exists for users to define groups of
users for the purpose of lDAC, the mechanisms for defining these
groups should be described.





3.2.4 DAC Errors and Their Causes


 •  The possible error messages that can occur when DAC commands
are improperly invoked should be noted and the correct or expected
inputs should be explained.



 •


3.3 MANDATORY ACCESS CONTROL FACILITIES


 •  This section is for systems in the B and A classes. It describes
the commands that a general user will need for dealing with labeled
objects.


3.3.1 Printing Labeled Objects


 •  This section describes the mechanism for printing or otherwise
producing non-electronic versions of labeled objects. Of specific
interest is the mechanism that would be used for overriding the
default printing of the object's label in human-readable form.
The description of this capability could be accompanied by a discussion
of the security considerations that go with its use.


3.3.2 Accessing Single-Level Devices


 •  This section should discuss the constraints on the use of
single-level devices in the presence of multiple authorization
levels. For example, this section could discuss how the TCB determines
a user's access to a single-level device based on the user's authorization
level.


3.3.3 Accessing Multilevel Devices


 •  This section should discuss the rules for the interaction
between users at multiple authorization levels and multilevel
devices.


3.3.4 Downgrading Labeled Objects


 •  Although it is not a part of TCSEC evaluations, if the system
offers an object downgrade facility that is available to the target
audience of the SFUG, this facility and cautions on its proper
use should be described.





3.3.5 MAC Errors and Their Causes


 •  The possible error messages that can occur `when MAC commands
are improperly invoked should be noted and the correct or expected
inputs should be explained.



 •



 •


3.4. OBJECT MANIPULATION FACILITIES


 •  This section should discuss the commands and mechanisms available
for dealing with objects.


3.4.1 Object Creation, Reuse, and Deletion


 •

 •  This section should discuss how the system creates, reuses,
and deletes user visible objects. Any commands which allow the
creation of user owned objects (e.g., mailboxes or blank files)
should be described. The information on object reuse should be
for informational purposes only, since all C2 and above systems
are required to do object reuse without user intervention. For
systems with MAC, this section should describe how sensitivity
labels and discretionary access lists are assigned to an object.




3.4.2 Importing Machine-Readable Objects


 •  The mechanisms for a user to introduce a machine-readable
object into the system from an external source (e.g., tape, removable
diskette, or network) and assign discretionary and mandatory access
control properties to it should be described if such a facility
exists.


3.4.3 Exporting Machine-Readable Objects


 •  The mechanisms for a user to export a machine readable object
from the system to an external source (e.g., tape, removable diskette,
or,network), along with its discretionary and mandatory access
control properties, should be described if such a facility exists.


3.4.4 Determining the Properties of Objects


 •  The commands or mechanisms for determining the discretionary
and mandatory access control properties of an object should be
described.





3.4.5 Object Manipulation Errors and Their Causes


 •  The possible error messages that can occur when object manipulation
commands are improperly invoked should be noted and the correct
or expected inputs should be explained.





THE TASK-ORIENTED SFUG



At a high level, the task-oriented example SFUG is arranged in
the following fashion:

 • 1. INTRODUCTION TO THE SFUG
 • 2. SYSTEM SECURITY OVERVIEW

 • 2.1 SYSTEM PHILOSOPHY OF PROTECTION
 • 2.2 DEFINITION OF TERMS AND SERVICES
 • 2.3 THE SYSTEM SECURITY OFFICER
 • 2.4 USER SECURITY RESPONSIBILITIES


 • 3. SECURITY-RELATED COMMANDS FOR USERS

 • 3.1 SYSTEM ACCESS

 • 3.1.1 Session Initiation
 • 3.1.2 Changing the Session Profile
 • 3.1.3 Changing the User Profile
 • 3.1.4 Potential Access Problems and Solutions


 • 3.2 ACCESS CONTROL FACILITIES
 • 3.3 PROTECTING REMOVABLE OBJECTS
 • 3.4 LOGGING SECURITY-RELEVANT EVENTS









The annotated outline follows.
1. INTRODUCTION TO THE SFUG


 •  This part of the SFUG should identify what the SFUG is, who
it is written for, and what it will cover. It might also explain
where the SFUG fits in with the rest of the user documentation.
If appropriate, it can also describe the relationship between
the SFUG and the TFM.



 •
 •


2. SYSTEM SECURITY OVERVIEW


 •  This section provides the background on the overall operation
of the security controls in the system so that users can then
understand the options and actions of individual security-relevant
commands.


2.1 SYSTEM PHILOSOPHY OF PROTECTION


 •  This section should describe the general environment for
which the system is designed and briefly explain how this environment
motivates the approach to protecting information stored in the
system. The purpose of this section is to lay the foundation for
the user's understanding of the system's security features, with
later sections detailing what specific security services are available
and when and how to use them.


2.2 DEFINITION OF TERMS AND SERVICES


 •  This section should first introduce the terms that will be
used to describe the security services available in the system
and then proceed to introduce those services, without detailing
exactly how they are used. Recommended topics (and the criteria
classes for.which they are relevant) for this section are:

 •  An explanation of the general concepts of subjects
and objects, followed by the identification of the subjects and
objects in the system.
 •  An explanation of object reuse and its role in protecting
information in the system.
 •  An explanation of the components of the I&A (identification
and authentication) process (e.g., user-id, password, or smartcard)
in the system and the importance of I&A to system security.
 •  An explanation of DAC, groups, privileges, protection
bits/ACLs (access control lists), and any other terms and concepts
related to the system's DAC policy, followed by a description
of how the DAC policy applies to the system subjects and objects.
 •  An explanation of MAC, security labels, sensitivity
levels, categories, authorizations, and any other terms and concepts
related to the system's MAC policy, followed by a description
of how the MAC policy applies to the system subjects and objects.







2.3 THE INFORMATION SYSTEM SECURITY OFFICER


 •  This section discusses the role of the information system
security officer (1SS0) in maintaining the security of the system.
It can also explain which problems should be reported to the 1SS0
and which should be reported to the system administrator (if the
roles are separate). If the format of the SFUG allows it, this
section could have space for site-specific notes on the 1SS0/user
relationship.


2.4 USER SECURITY RESPONSIBILITIES


 •  This section discusses the user's responsibilities with respect
to properly using the system security features. This would optimally
be a tutorial that teaches effective use of the system security
services, but any presentation that relates the security services
to the user's day-to-day use of the system is appropriate. Some
issues that might be addressed are:



 •  Authentication token (e.g., password or smartcard)
protection.
 •  Warnings about leaving a terminal unattended.
 •  Procedures for "locking" a process when the
terminal must be left unattended, but logged in.
 •  Default DAC access for named objects (e.g., files and
directories).
 •  Cautions about using programs that are not part of
the standard system configuration (e.g., utilities or applications
that have not been reviewed and tested by the system administrator(s)).
 •  Cautions about the effect of network access on system
and data security.





3. SECURITY-RELATED COMMANDS FOR USERS


 •        This section comprises the majority of the SFUG since
it describes in detail the commands and procedures for actually
using the system. It should describe both the usage of the commands
and reemphasize their role as tools to protect information stored
on the system. For example, this part might consist of command
reference pages (e.g., UNIX "man" pages) grouped by
subject, possibly with a brief introduction at the beginning of
each subject area.  Alternatively, this section could contain
general descriptions of the operation and options of individual
commands or groups of commands, along with pointers to the detailed
documentation of the invocation sequence(s) for the commands.





3.1 SYSTEM ACCESS


 •  This section should explain the procedures for logging on
and off the system. It should also discuss how the TCB assigns
privileges and authorizations during the login process and how
the user can change them during the session (if the system allows
in-session changes). This section might also discuss how users
can prevent and detect compromise of their accounts. For systems
that provide trusted path during a session, this section of the
SFUG should describe the mechanism for invoking the trusted path
and the effect of the invocation on the currently running process.
Finally, the errors that might occur during the use of these commands
and corrective actions should be described here.


3.1.1 Session Initiation


 •  This section should describe the procedures that a user goes
through to establish a session with the system. In B2 nd above
systems, this discussion will start by describing how a user establishes
a trusted path between the terminal and the TCB. For any system,
it will discuss the procedure for presenting the identification
and authentication tokens (typically a user-id and password) to
the system so that the system can establish a subject to act on
behalf of the user. When the login process provides the means
for overriding the default group/project and subject sensitivity
level, the use of these options should be described.





3.1.2 Changing the Session Profile


 •  When the system provides the facilities for the user to dynamically
modify his or her group/project participation and/or subject sensitivity
level, this section should describe them.


3.1.3 Changing the User Profile


 •  Many systems have the concept of a user profile, which contains
the default settings for the creation of a user subject. Although
it may actually be maintained separately, the user password is
logically part of this profile. This section should provide information
on how to modify the parts of the user profile over which the
user has control. At a minimum, this section should show how the
user can change his or her password (for systems where the password
is the authentication token).


3.1.4 Potential Access Problems and Solutions


 •  This section should discuss the possible problems that a
user could encounter when logging into the system or modifying
session and user profiles. This section could be organized as
a troubleshooting guide, where each problem and its potential
solution(s) is presented in a table format.


3.2 ACCESS CONTROL FACILITIES


 •  This section describes the commands available to a user for
managing the objects under his or her control. The major issue
confronting the SFUG author in this section is how to organize
the commands. Two possible options are:

 •  By security policy functionality, i.e., all commands
that manipulate MAC attributes, DAC attributes, exportation to
devices, labeled human-readable output etc.
 •  By target object class, i.e., all security-relevant
commands that manipulate files, directories, printers, tape drives,
interprocess communication, floppy disks, etc.








 •  Experience during previous evaluations indicates that the
second option more closely matches the needs of the user, since
it is closer to the organization expected when trying to search
for a specific command to do a specific job.





3.3 PROTECTING REMOVABLE OBJECTS


 •  This section should discuss some of the basic actions that
a user should take to ensure that the data contained in hardcopy
or external storage form is protected as fully as when it is on
the computer system. In a site-specific SFUG, this section could
be an even stronger statement regarding the site's procedures
for protecting information once it leaves the system.


3.4 LOGGING SECURITY-RELEVANT EVENTS


 •  In some systems, it may be possible for users to do limited
auditing on the objects over which they have control. In these
cases, the commands available to the user for this purpose should
be described.





BIBLIOGRAPHY


 • 1. DoD Trusted Computer System Evaluation criteria, Natonal
Computer Security Center, DoD 5200.28-STD, 1985.
 • 2. American Telephone and Telegraph System V/MLS Release 1.1.2
Running on UNIX System V Release 3.1.1 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-89/003, October 1989.
 •  This FER identified the following four documents as the SFUG
for this product:

 •  System V/MLS User's Guide and Reference Manual, August
1989,
 •  630/MLS User's Guide, August 1989,
 •  302 UNIX System V Programmer's Reference Manual, August
1989,
 •  UNIX System V User's Guide, August 1989.








 • 3. Computer Associates International CA-ACF2/VM, Release 3.1
(Final Evaluation Report), National Computer Security Center,
CSC-EPL-87/007, September 1987.
 •  This FER identified the following four documents as the SFUG
for this product:

 •  Overview for CA-ACF2/""M Release 3.1, Publication
Number AAG0042, Sept



 •  1987,



 •  General Information Manual for CA-ACF2/""M
Release 3.1, PN AAG0033,



 •  5ept1987,



 •  New Features and Enhancements Manual for CA-ACF2NM
Release 3.1, PN



 •  AAP0073, Sept 1987,



 •  User's Guide for CA-ACF2NM Release 3.1, PN AAP0037,
Sept 1987.








 • 4. Computer Associates International Top Secret, Version 3.0
(Final Evaluation Report), DoD Computer Security Center, CSC-EPL-85/002,,-
April 1985.
 •  This FER identified the following two documents as the SFUG
for this product:

 •  TOP SECRET User's Guide, Document US-03, 1985,
 •  TOP SECRET TSS Reference Manual, Document TS-03, 1985.
 •









5. Control Data Corporation Network Operating System Security
Evaluation Package (Final Evaluation Report), National Computer
Security Center, CSC-EPL-86/003, May 1986.

 •  This FER identified the following document as the SFUG for
this product:

 •  NOS Version 2 Reference Set, Volume 2: Guide to System
Usage, Section 14, Publication Number 60459670, Revision D, 1986.








 • 6. Digital Equipment Corporation VAX/VMS, Version 4.3 (Final
Evaluation Report), National Computer Security Center, CSC-EPL-86/004,
July 1986.
 •  This FER identified the following document as the SFUG for
this product:

 •  Guide to VAX/VMS System Security, Chapters 1-4, AA-Y51
0A-TE, AA-Y51 0A-Tl, VAX/VMS Version 4.2, July 1985.








 • 7. Data General Corporation Advanced Operating System/Virtual
Storage (A 05/VS) (Final Evaluation Report), National Computer
Security Center, CSC-EPL-89/001, February 1989.
 •  This FER identified the following two documents as the SFUG
for this product:

 •  Learning to Use Your AOS/VS System, Product Number
069-000031-02,



 •  November 1088,



 •  AOS/VS System Calls Dictionary, Product Number 093-000241-03,
September 1986.








 • 8. Gould, Inc Computer Systems Division UTX/32S, Release 1.0
(Final Evaluation Report), National Computer Security Center,
CSC-EPL-86/007, December 1986.
 •  This FER identified the following document as the SFUG for
this product:

 •  Using Gould UTX/325, Release 1.0, which is Volume 1
of Gould UTX/32S Document Set, Volume Order Number 323-005231-000,
November 1986.








 • 9. Hewlett Packard Commercial Systems Division MPE v/E (Final
Evaluation Report), National Computer Security Center, CSC-EPL-88/01
0, October 1988.
 •  This FER identified the following document as the SFUG for
this product:

 •  MPE V/E Security and Account Structure User's Guide,
Product Number 32033-90136, October 1988.








 • 10. Honeywell MULTICS, MR1 1.0 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-85/003, June 1986.
 •  This FER identified the following document as the SFUG for
this product:

 •  Multics Programmers Reference Manual, Chapter 6, Order
Number AG91 - 04,1986.








 • 11. Honeywell SCOMP (Secure Communications Processor) STOP
Release 2.1 (Final Evaluation Report), DoD Computer Security Center,
CSC-EPL-85/001, September 1985.
 •  This FER identified the following document as the SFUG for
this product:

 •  SCOMP User's Reference Manual, STOP Release 2.1, November
1984.








 • 12. International Business Machines Resource Access Control
Facility (RACF), Version 1, Release 5 (Final Evaluation Report),
DoD Computer Security Center, CSC-EPL-84/001, July 1984.
 •  This FER identified the following document as the SFUG for
this product:

 •  OS/VS2 MVS Resource Access Control Facility (RACF):
General Information Manual, 5C28-0722-6, 1984.








 • 13. International Business Machines Corporation VM/SP with
RACF (Final Evaluation Report), National Computer Security Center,
CSC-EPL-89/005, September 1989.
 •  This FER identified the following six documents as the SFUG
for this product:

 •  "Part Three: For General Users" in Virtual
Machine/System Product C2 Security Guide VMISP Release 5 and VM/SP
HPO Release 5, Library Number



 •  5C24-5384-0,' no date,



 •  RACF General User's Guide, Library Number 5C28-1341,
December 1987,
 •  VM/SP CMS Command Reference, Library Number SCl 9-6209,
no date,
 •  VM/Directory Maintenance Operation and Use, Library~Number
5C23-0437,



 •  March 1989,



 •  VMTAPE-MS User's Guide, Library Number 5H20-6245, September
1988,
 •  The VM HELP Facility, online function.









14. Prime Computer, Inc PRlMOS Rev 21.0.1. DODC2A (Final Evaluation
Report), National Computer Security Center, CSC-EPL88/009, July
1988.

 •  This FER identified the following document as the SFUG for
this product:

 •  Security Features User's Guide, 1st Edition for Revision
21.0, 1987.








 • 15. UNlSYS Corporation A Series MCP/AS Release 3.7 (Final
Evaluation Report), National Computer Security Center, CSC-EPL-87/003,
August 1987.
 •  This FER identified the following document as the SFUG for
this product:

 •  A Series Security Features Operations and Programming
Guide, Document Number 1195203, July 1987.








 • 16. UNlSYS Corporation OS 1100 (Final Evaluation Report),
National Computer Security Center, CSC-EPL-89/004, September 1989.
 •  This FER identified the following document as the SFUG for
this product:




OS 1100 Security System Operations Guide, UP-I 3011.1, August
1989.



b